Yet Another Optimization Article

T his is a troubling column to write. I hadn't planned to write on optimization , because what I have to say has already been said numerous times. Yet, when I give talks, I find there's still a surprising number of people who don't know, or at least don't follow, the advice I'm about to give. So, here goes. (Many of you have probably seen this advice before—my thought to you is to ponder why I need to say this again.) First, performance matters. Although relying on Moore's law to get us out of slow programs has its merits, I find it increasingly annoying when I get a new version of a program and must upgrade my hardware for it to work acceptably. The question is, " How do we achieve a fast program? " For many programmers, performance is something you pay continuous attention to as you program. Every time you write a fragment of code, you consider the performance implications and code the program to maximize performance. This is an obvious technique—pity it works so badly. Performance is not something you can work on in this way. It involves specific discipline. Some performance work comes from architectural decisions, some from a more tactical optimization activity. But what both share is the fact that it is difficult to make decisions about performance from just looking at the design. Rather, you have to actually run the code and measure performance. Steps for optimization Optimizing an existing program follows a specific set of steps. First, you need a pro-filer—a program that can analyze how much time your program spends in its various parts. Software performance has an 80/20 rule: 80 percent of the program's time is spent on about 20 percent of the code. Trying to optimize performance in the 80 percent of code is futile, so the first order of business is to find that 20 percent of code. Trying to deduce where the program will spend its time is also futile. I know plenty of experienced programmers who always get this wrong. You have to use a profiler. To give the profiler something to chew on, perform some kind of automated run that reasonably simulates the program under its usual conditions. An automated test suite is a good starting point, but make sure you simulate the actual conditions. My colleague Dave Rice has a rule: " Never optimize a …